home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir34 / dos999.zip / 2603.TXT < prev    next >
Text File  |  1993-04-13  |  7KB  |  131 lines
  1. _________________________________________________________________________
  2. STACKER NOTE                                                 STACKER NOTE
  3.  
  4. Subject: Stacker and "Slack" Space.
  5.  
  6. STAC FAX Index #2603 - 5/13/92
  7. Page 1 of 2
  8. __________________________________________________________________________
  9. Definitions:
  10.  
  11. Sector: The smallest unit of storage that a disk controller is
  12.         physically able to read or write.  Sectors have a fixed 
  13.         size of 512 bytes in a Stacker drive.
  14.  
  15. Cluster (Allocation Unit):  A multi-sector unit; the smallest
  16.         unit of storage used by DOS.  DOS varies the allocation unit size
  17.         to suit the storage medium, however, the size is set during
  18.         logical formatting and does not change thereafter.  Called a
  19.         cluster prior to MS-DOS 4.0, the words are interchangeable.
  20.  
  21. The DOS 16-bit FAT is limited to 64K, therefore the maximum drive
  22. size with 2K clusters is 128Mb (64K x 2K).  When the drive being
  23. formatted is larger than 128Mb, DOS merely makes the allocation 
  24. units bigger, because the limitation on drive size is the number 
  25. of clusters, not the number of sectors.  This would suggest to 
  26. those of you who write many letters and other small documents, 
  27. or who use relatively small database and spreadsheets, that you 
  28. should probably not partition a drive over 128Mb, because from 
  29. 128Mb to 256Mb, DOS uses 4K allocation units.  From 256Mb to 512Mb, 
  30. the allocation units are 8K.  As the drive gets bigger, the allocation 
  31. units get proportionally larger also.
  32.  
  33. Slack Space:The space lost on your hard disk when DOS allocates
  34.       an entire cluster to save an amount of data which is less than
  35.       the size of that cluster.
  36.           e.g.: Your file is 612 bytes, so normally DOS uses one
  37.       allocation unit (cluster) to save the 612 bytes.    Because an
  38.       allocation unit is 2048 bytes, the lost space (slack space) is
  39.       1436 bytes (2048 - 612).  
  40.       
  41.       The larger the drive, the larger the allocation unit, and the 
  42.       greater the amount of slack space (waste).  If your drive has 8K 
  43.       allocation units, and you save a 178 byte batch file (filename.bat), 
  44.       the wasted space is 8014 bytes.  A normal letter would waste from 5K 
  45.       to 7K.  This space is lost forever, unless we change the size of the 
  46.       allocation units on this particular drive.
  47.  
  48. Stacker and flexible allocation units:
  49.  
  50. Stac had a better idea, we decided to have a flexible
  51. allocation unit.  When Stacker builds a new drive, the default
  52. cluster size is 8K.  What this really means is that the largest
  53. possible cluster size is 8K, not that all clusters are 8K.  This
  54. allows Stacker to build a drive as large as 512Mb logical (64K x
  55. 8K).  Where Stacker saves space is in the use of sectors.  When
  56. Stacker saves a file which is less than a sector in size, it only
  57. allocates one real sector to the cluster which is keeping track
  58. of that data.  Therefore, if the compressed data is 6 bytes,
  59. Stacker only uses one sector to save that file, whereas DOS would
  60. use 4 sectors, so the savings in lost space is 1536 bytes (2042 -
  61. 506).
  62.  
  63. More simply stated; Stacker only uses as many sectors as
  64. necessary for a given file.  Sectors are not tied permanently to
  65. a specific allocation unit until they are used, and even then,
  66. only enough are used to do the job.  This means that slack space
  67. is greatly reduced in a Stacker drive.
  68.  
  69. Of course, there is a slight catch: too many small files only use
  70. one or two sectors each, but each one also uses an allocation
  71. unit.  This means that the FAT can run out of entries even while
  72. much of the space is unused because the sectors were not
  73. allocated to clusters.
  74.  
  75. In Stacker version 1.x, the only fix for this problem was to
  76. change the cluster size to 4K.  This allows twice as many entries
  77. in the FAT.  This method can also be used with Stacker version
  78. 2.0 by users of DOS versions which are limited to 32Mb drives.
  79.  
  80. In Stacker version 2.0, Stac improved the product by allowing the
  81. user to logically "grow" an existing Stacker drive with a high
  82. compression ratio, by increasing the number of allocation units.  
  83. When the drive is getting close to full, and the compression ratio 
  84. is appreciably higher than the original ratio, the user may choose to 
  85. "grow" the drive by running SDEFRAG /G.  This can increase the number
  86. of allocation units up to twice the original number, thereby increasing
  87. the logical capacity.
  88.  
  89. For the user of a database file which is approximately 400Mb, and
  90. which compresses at 8:1, we need to do a little arithmetic before
  91. building the original Stacker file.  The maximum size of a
  92. Stacker drive is 512Mb.  Divide this by the anticipated maximum
  93. compression ratio of 8, and we get 64Mb.  Therefore we can create
  94. a new Stacker drive, choose a compression ratio of 8:1, and stack
  95. an existing drive with its data.  If the data really compresses
  96. at 8:1, we will have used 64Mb of physical space to create a
  97. drive of 512Mb.  If the file is very large, there will be no
  98. slack space, as the file is many clusters long.  The FAT is still
  99. only 64K, but is now handling a very large drive in a relatively 
  100. small space.
  101.  
  102. To prove this, you can conduct a fairly simple test.
  103. First, run SCHECK on a Stacker drive, and record the results
  104. which should look like this:
  105.  
  106. No errors found
  107. Stacker Drive Statistics:
  108.              Stacker Drive               STACVOL File
  109.                 Drive C:                 D:\STACVOL.DSK
  110.              ______________              ______________
  111.  
  112. Total Bytes:     155,435,008               77,718,016
  113. Bytes Used:       80,887,808  ( 52.0% )    44,773,888  ( 57.6% )
  114. Bytes Free:       74,547,200  ( 48.0% )    32,944,128  ( 42.4% )
  115.  
  116. Stacker Drive Compression Ratio = 1.8:1
  117. Projected Bytes Free           = 59,473,920
  118.  
  119.      The important number to observe here is the bytes used in
  120. the STACVOL file (44,773,888 bytes).
  121.  
  122. Second, create a very small file, or copy a small file from
  123. anywhere.  Make sure that the file is less than 512 bytes.  Now
  124. run SCHECK again, and look at the number of bytes used in the
  125. STACVOL file again.  This time, the number should be 512 bytes
  126. less.  Record the number again, and now add another file which is
  127. somewhat larger, and then look at the results again.  This time
  128. the bytes free may decrement by 512 or 1024 or 1536 or 2048 or
  129. some other multiple of 512.  This should demonstrate that Stacker
  130. only uses as many sectors as it needs, no more.
  131.